A consumer Service Provider (CSP) is an entity that offers one or more electronic commerce (EC) services to a base of customers. The customers can be individuals, businesses, organizations, or any other type entity utilizing EC services. CSPs offer EC services via one or more networks, typically the Internet, though some CSPs offer EC services via other public and proprietary networks. Different CSPs may offer different EC services. Further, some CSPs offer other services than EC services. Examples of CSPs include financial institutions, Web portals, or other types of Web sites or business entities. CSPs are also known as sponsors.
A service Provider (SP) is an entity that provides EC functionality. A SP can provide EC functionality on behalf of one or more CSPs, or directly to customers not associated with CSPs. Typically, when a SP provides EC functionality on behalf of a CSP, a customer of the CSP accesses the CSP and is redirected to the service provider. Alternatively, a SP acting on behalf of a CSP sometimes has no communication with a customer. In such situations, the CSP interacts with both a customer and the SP. Communications between the CSP and the SP in such situations are by way of an application program interface (API), such as CSAPI (online in-session) or SIS (batch out-of-session). Often the fact that a SP is providing functionality on behalf of a CSP is unknown to the consumer. That is, a SP acts behind the scenes on behalf of a CSP. A service provider also often provides EC functionality directly to customers. That is, in these situations, a SP is not acting on behalf of a CSP. For those customers not utilizing a CSP, they directly access the service provider via a network. Also, some SPs provide functionality for other types of services other than EC services. EC functionality directly to customers. That is, in these situations, a SP is not acting on behalf of a CSP. For those customers not utilizing a CSP, they directly access the service provider via a network. Also, some SPs provide functionality for other types of services other than EC services.
A product is a client user interface (UI) that supports one or more EC or other services. Products include proprietary PC-based UIs, proprietary telephone-based UIs, proprietary Web-based UIs, and proprietary wireless UIs, as well as third party UIs. Different versions of a given product may support different services, or differently support the same service or services.
EC Services, introduced above, is a set of related electronic commerce services that is offered across different products. Examples of EC services include bill payment, electronic billing, and person-to-person payment. Other EC services include investment services, such as security trading, portfolio management, and financial planning, retail point-of-sale payments, Web-based retail purchases, tax filings and associated payments, and financial records reconciliation. Electronic bill presentment and payment services are often bundled together, and are commonly known as electronic billing and payment (EBP) services. The same service is often supported differently across products. The processing to support a service can be different across products, and features of a service can be different across products.
FIG. 1 is a simplified depiction of the relationships between a service provider 101, a CSP 105, and multiple customers C.sub.1-C.sub.N. As shown, customers C.sub.1-C.sub.3 and C.sub.16-C.sub.N are provided EC services via a first product, P.sub.1, customers C.sub.4-C.sub.6 and C.sub.10-C.sub.12 are provided EC services via a second product, P.sub.2, and customers C.sub.7-C.sub.9 and C.sub.13-C.sub.15 are provided EC services via third product, P.sub.3. Customers C.sub.1-C.sub.9 access EC services through CSP 105, and customers C.sub.10-C.sub.N access EC services directly through the service provider 101. Customers utilizing the same product access either the SP 101 or the CSP 105 via the same type network, i.e., the Internet, another public network, a propriety network, or the public switched telephone network.
At step 170 the identity of the CSP with which the customer is associated is determined from data stored in the interoperability database (customer profile data). The service provider 201 then accesses the interoperability database (CSP profile data) and attempts to locate information associated with the customer's CSP, step 180. The service provider 201, at step 190, determines if information associated with the customer's CSP is found in the interoperability database. If not, an error message is returned, step 200, and the session is terminated, step 370 (FIG. 3C). If the service provider 201 determines that information associated with the CSP is included in the interoperability database, operations continue with step 220.
Each product, P1-P3, is independent of the other products. Each product is often independently developed, resulting in each product typically having a unique user interface, unique processing to deliver a service, and unique EC service features. That is, while multiple products may offer one or more of the same EC services, such as bill payment, the processing to achieve that same service, and the features of that same service, often differ between products. Furthermore, each product is associated with a unique data repository. Each repository includes data associated with those customers utilizing that product. Thus, each product can be thought of as an independent silo. The products are not interoperable. That is, there is no linkage between the products.
A customer, according to prior art techniques, can access EC services through more than one product (client UI). However, services provided via one product have no bearing on services offered in other products. This is because, as discussed above, each product is independent of the other products. Thus, for example, a payment directed by the customer using one product would not show up on a payment history accessed using another product, and a transaction submitted via one product could not be modified via another product.
Accordingly, a need exists for a technique for accessing EC services via multiple products in which actions taken via one of the multiple products are reflected in the other products.
Also, a need exists for a technique for accessing EC services via multiple products in which a transaction submitted via one of the multiple products can later be modified via another of the multiple products.
Introduced above, different EC services are often offered via different products, even when those products are supported by the same service provider and accessed via the same CSP. Additionally, when the same EC service is offered via different products by the same service provider, the features of that EC service are often different among the various products.
For example, a first product may offer a pay-anyone bill payment service and an electronic billing service, and a second product may offer a pay-anyone bill payment service and a person-to-person payment service. Further, the first product may offer extended payment information fields in the pay-anyone bill payment service, whereas the second product may not. In this example, electronic billing and extended payment information fields would have no meaning in the second product. Likewise, person-to-person payments would have no meaning in the first product. This situation is often referred to as an impedance mismatch. Thus, the first and the second product cannot be interoperable, because a service of one product is not available in the other product, and because a feature in one product is not present in the other product.
One proposed technique for overcoming impedance mismatch between products is to modify the services and/or features offered in the products to be the same. That is, the services and/or products offered would be the lowest common denominator among the products. That is, if certain functionality cannot be supported by a given product, that functionality would not be offered in any product. This is undesirable because it results in no differentiation between the products.
Accordingly, a need exists for a technique to provide multiple interoperable products in which the unique characteristics of each product are retained.
Though not depicted in FIG. 1, a service provider is typically associated with multiple CSPs. Different CSPs have different customer bases, having different EC needs. Furthermore, different CSPs have different business models. These factors result in different CSPs offering different combinations of EC services and products to their customer base, even when the same service provider provides the EC services. Also, some CSPs offer different combinations of services and products to different customers. CSPs may offer different combinations for a variety of reasons, including providing choice and convenience to their customers. Furthermore, some CSPs offer “value-add” features to an offered service. A product including a value-add feature can be thought of as one version of a product. Often times a value-add feature is only offered to a portion of a CSPs customer base, and often for a fee.
Discussed above, one proposed method of providing interoperable products is to modify the products to offer the same services and features. Such a solution is inconsistent with different CSPs offering different services or value-add features, as there would be no differentiation between the products.
Accordingly, a need exists for a technique for providing interoperable products in which different combinations of products can be offered in an interoperable fashion.
Also, a need exists for a technique for providing interoperable products in which different combinations of services and features can be offered in an interoperable fashion.